Co-authored-by: Ed Cormany <[email protected]>

…leAreasInProtocol (#14205)

adds the moveToAddressableAreaForDropTip command to the getAddressableAreasInProtocol helper that
provides a list of addressable area names referenced in a protocol's commands

This PR is a general second-pass of the drop tip wizard. There's a good bit refactoring, but in terms of functional changes:

  - The wizard doesn't render BeforeBeginning until the maintenance run has been successfully created - renders a spinner now. This prevents some bugs and is better UX.
  - Exiting the drop tip wizard now renders a spinner and exits properly.
  - The home command occurs in a predictable spot - no more instantly homing after completing blowout.
  - Use moveToAddressableArea instead of moveRelative to prevent unexpected pipette movements (you CANNOT move to a slot with a moveable trash or waste chute loaded -- this is a known issue and currently being fixed).
  - Fixes an issue where an unreachable step could be hit.
  - More error messaging!
NOTE: you CANNOT move to a slot with a moveable trash or waste chute loaded -- this is a known issue and currently being addressed separately.

Closes RQA-2083, RQA-2094, RQA-2066, RQA-2068, RQA-2024

…rd (#14210)

translates a selected "slot" to an addressable area compatible with the configured deck and selected
pipette.

closes RQA-2099

Implement the tcp socket emulator by creating a separate stream
that is piped through to the usb connection via its downward interface
rather than using the same stream for both the port and the socket or
pipelining the two streams together.

This implementation allows the lifecycles of the USB port connection,
which we want to be the same as the physical robot connection; and the
tcp socket emulators, which we want to be more like tcp sockets; to be
separate, which really increases reliability because we don't have the
port going up and down all the time anymore. This reduces spurious
disconnects.

It will also allow us to add socket activity timeouts to help with the
windows dropping data problem, though we can't really do that until the
http requests that cause synchronous actions that we make get keep alive
streaming responses.

Since on the 96, that moves motors while someone is holding it in their hands.

Closes RQA-2106

* refactor(app): remove drop tip banner for ot2 after protocol runs

* refactor(app): add more error handling to drop tip wizard moveToAddressableArea

* style(app): add sensible text when drop tip launches

* fix(app): cancelling a run should not unrender drop tip banner

* fix(app): include fixed trash as a moveToAddressableArea zoffset exception

* fix(app): do not show drop tip/blowout confirmation until moveToAddressableArea has completed

* refactor(app): add even more error handling - this time to the droptip and blowout commands

* fix(app): fix estop modal button state issue

…tions (#14220)

Fix bug in which moves to manual moves to addressable areas would show nothing in the manual
intervention modal

Closes RQA-2114, Closes RQA-2115

adjusts BaseDeck styling of slot labels, staging area slot clip positioning, and colors to match
design system deck map

closes RAUT-902, RAUT-861

…14218)

* fix(app): remove dismissCurrentRun when run is cancelled on ODD

Mirror the desktop app. Dismissing the run context on run cancel means drop tip will not work.

This seems like a logic problem with how we track tip state, but
removing this check (which is really a nebulous "might be using it
wrong" check) we fix some incorrect errors in the drop tip wizard.

* fix(app): allow users to use the same name after clearing all data

ensures that all OT2 protocols auto drop tips regardless of version, and that only Flex protocols 2.15 and prior auto drop tips

We have a system to center pipettes appropriately on the wells of
labware that span multiple "traditional" wells. For instance, in a
12-well reservoir, we need to move the center of an eight channel
pipette to the center of a given well of the 12-well reservoir.

However, that code was moving the center of _any_ pipette to the center
of a 12-well reservoir, inclunding the center of the 96-channel, which
is definitely not right. Instead, what we want to do is move the center
of the "active" column (the column that contains the active nozzle,
which is the nozzle that is moved when a caller specifies a NOZZLE
critical point) to the center of the well. And we only want to do this
on labware that have roughly one well per column.

The fix is in two parts.

First, a Y_CENTER critical point needs to exist. This critical point is
aligned in the X direction with the active nozzle of the pipette, but is
halfway between the Y positions of the backmost and frontmost nozzles in
the column containing the active nozzle of the currently active
nozzlemap - so, on an eight channel with a full map it would be the same
as XY_CENTER; on a single, an eight channel with a single nozzle map, or
a 96 with a single nozzle map, it will be the same as NOZZLE (and the
same as XY_CENTER); and on an eight channel or 96 with a partial-column map it will
be halfway up the partial.

On a 96 with a rectangular map (i.e. either full or quadrant) it will be
halfway between the back left and front left nozzles.

Next, we have to actually use that critical point. The engine would
check for a labware to have the centerMultiChannelOnWells quirk and emit
XY_CENTER for both source and destination if it was found; we now also
consider how many wells the labware has if it has
centerMultiChannelOnWells and (somewhat hackily, sadly) emit
- Y_CENTER, if the labware has the centerMultiChannelOnWells quirk and
1 < wells < 96
- XY_CENTER, if the labware has the centerMultiChannelOnWells quirk and
wells == 1, wells >= 96

This should probably change eventually into a new quirk called like
centerActiveColumnOnWells or something but that's for a different time.

Closes RQA-2118

* fix(app): add dimsissing current run back

* fix(app): fix robot stuck in cancelled state

* test fixes

…ash (#14151)

A previous PR (12a630b / #13989 ) changed the python protocol api in version 2.16 to allow commanding 0ul liquid handling commands like aspirate, mix, and dispense. This is useful in programmatic protocols that read out volumes to handle; they can now handle 0 volume properly. In 2.15 and previous, specifying 0 would lead to those commands doing the most volume they could (i.e. aspirate the full tip volume, dispense whatever's currently in the pipette, mix at full volume) and this likely was an unintentional side effect because of python truthiness.

However, that change only touched the python protocol API; that API would emit commands to the engine that specified 0 volume, and those were not allowed: the pydantic models for the commands and responses required strictly greater than 0 volume.

This PR

- changes the pydantic models and updates the schema to allow 0ul commands
- adds a python protocol to be an integration test
- adds unit tests for the python protocol api aspirate and dispense commands



---------

Co-authored-by: Seth Foster <[email protected]>
Co-authored-by: Max Marrone <[email protected]>

---------

Co-authored-by: Max Marrone <[email protected]>

…#14233)

Closes RQA-2013

* fix(app): fix viewing error modal dismissing error and drop tip banners

* refactor(app): refactor useMostRunRecentId to be safer

…mp module v2 (#14235)

* fix(app): add new text to updatebanner for module card

…ozzle configuration (#14231)

Raises error when pick_up_tip is called without a location when using pipette nozzle configurations that aren't supported in 7 1

closes RQA-2137

…ending (#14234)

* feat(app): add gradient scrim to ODD protocol command list

closes RQA-1630

---------

Co-authored-by: Max Marrone <[email protected]>

* refactor(app): remove excessive axis homing

Now that moveToAddressableArea provides the ability to home to Z axis before moving, let's remove the
homing done during the flows but keep still keep the homing behavior at the end of the flow.